The present invention relates generally to telecommunication systems, and more particularly to packet data protocols for use in such systems.
In third generation telecommunication systems, such as the Universal Mobile Telecommunication System (UMTS), broad bandwidth is provided for services such as data and multimedia in addition to voice. It is desirable in such systems to provide users with an ability to establish a required Quality of Service (QoS). However, QoS cannot be guaranteed in certain types of networks, such as Internet Protocol (IP) networks or more generally the Internet, unless resources are reserved.
An end-to-end protocol known as Resource Reservation Protocol (RSVP) is currently used to allow these and other types of networks to reserve the resources required to provide a desired QoS. RSVP is described in Internet Engineering Task Force (IETF) RFC2205, Resource Reservation Protocol (RSVP), R. Braden et al., September 1997, which is incorporated by reference herein.
FIG. 1 illustrates the operation of RSVP. A transmitting user 10 sends to a receiving user 12 a PATH message. The PATH message carries traffic characteristics information such as information commonly known as xe2x80x9cTSpecsxe2x80x9d to indicate characteristics of the traffic that is to be sent from the transmitting user 10. When the receiving user 12 receives the PATH message, it sends a RESV message that contains a QoS request such as that commonly known as xe2x80x9cFlowSpecs.xe2x80x9d In practice, the transmitting and receiving users 10 and 12 can be located remotely so that the PATH and RESV messages pass through several nodes of a network. As each node receives both messages, it makes the decision as to whether adequate resources in that node can be reserved. If this is possible, then the messages are relayed to the next hop for the PATH message and the previous hop for the RESV message. When the RESV message reaches the transmitting user 10, it begins to transmit data. Periodic refresh messages are sent subsequently to maintain the QoS status at each node that has been set up.
European Patent Application No. 00301782.9, filed Mar. 3, 2000 in the name of inventor X. Chen and entitled xe2x80x9cResource Reservation in 3G or Future Generation Telecommunication Network,xe2x80x9d subsequently published on May 9, 2001 as European Patent Application EP 1 130 931 A1, describes methods for reserving resources in third or future generations of wireless mobile networks such as UMTS. Advantageously, the methods described therein have no or minimal impact on existing architecture or QoS procedures, and minimize any extra signaling traffic associated with supporting RSVP in UMTS.
As indicated in FIG. 1, conventional RSVP is a unidirectional QoS signaling protocol that delivers a QoS request from a traffic receiver to a traffic transmitter. The negotiated QoS set up via RSVP applies only to the traffic flowing in the direction from the traffic transmitter to the receiver. For the negotiation of the QoS requirement of the traffic in the opposite direction, a separate RSVP session must be initiated.
A problem which arises in the implementation of RSVP in UMTS and other types of systems is that such systems generally make clear distinctions between QoS for traffic flowing in an uplink direction from a Mobile Terminal (MT) to the network and traffic flowing in a downlink direction from the network to the MT. For example, such a distinction is made in the QoS Information Element (IE) of the Packet Data Protocol (PDP) Context of the UMTS standard.
Direct extension of the existing one-way PDP Context to cover both uplink and downlink traffic can lead to a xe2x80x9cracingxe2x80x9d problem. More particularly, users may send RSVP messages for QoS control in the uplink direction independently from corresponding RSVP messages for QoS control sent in the downlink direction. Therefore, when a given MT and a corresponding Gateway GPRS (General Packet Radio Service) Support Node (GGSN) receive RSVP messages, different PDP context control procedures need to be initiated for the RSVP session associated with each direction. This may result in a successfully established PDP context in one direction but a failed PDP context in the opposite direction for a session that desires reserved resources in both directions.
It is therefore apparent that a need exists in UMTS or another type of telecommunication system for a two-way PDP context procedure that applies to both uplink and downlink traffic and which solves the above-described racing problem.
The present invention provides two-way packet data protocol (PDP) techniques for use in UMTS and other telecommunication systems.
In accordance with the invention, a determination is made as to whether a user requires resource reservations in both an uplink direction and a downlink direction within the system. If the user requires the two-way resource reservations, a two-way protocol is implemented to establish the required resource reservations. The two-way protocol integrates resource negotiation procedures for both the uplink direction and the downlink direction so as to ensure that the required resource reservations are provided for both directions. The two-way protocol may be a Packet Data Protocol (PDP) based on a Resource Reservation Protocol (RSVP) resource negotiation procedure.
The above-noted determination as two whether the user requires two-way resource reservations may be based on one or more flag bits which identify whether the user requires resource reservations for both the uplink and downlink directions. The flag bits may be associated with a Quality of Service (QoS) Information Element (IE) of the system, and may be used to permit the user to select between application of the two-way protocol and application of a one-way protocol. For example, a pair of flag bits may be used, with the values of the bits indicating whether the user needs no resource reservations in either the uplink direction or the downlink direction, resource reservations in only the uplink direction, resource reservations in only the downlink direction, or resource reservations in both the uplink and downlink directions. As another example, a single flag bit may be used to indicate for a given direction of resource reservation requirement whether or not the resource reservation requirement is coupled with a corresponding resource reservation requirement in the opposite direction.
Advantageously, the two-way protocol techniques of the present invention efficiently handle resource reservations for both uplink and downlink traffic, and overcome the racing problem inherent in the implementation of QoS in the current one-way PDP context of UMTS.